IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) and ETSI TISPAN group to provide IP Multimedia services over mobile communication networks. (This technology is described in various technical documents some of which are referenced in the following description, and include 3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7, and TS24.173 Release 7.) IMS provides key features to enrich the end-subscriber person-to-person communication experience through the use of standardised NS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between subscriber terminals (or subscriber terminals and application servers). Whilst SIP was created as a subscriber-to-subscriber protocol, IMS allows operators and service providers to control subscriber access to services and to charge subscribers accordingly.
By way of example, FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the subscriber; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface.
The S-CSCF is the central node of the signaling plane. It is a SIP server, but performs session control as well. It uses Diameter Cx and Dx interfaces to download and upload user profiles to/from the user's Home Subscriber Server (HSS). The S-CSCF handles SIP registrations, and is in the path of all signaling messages, so that it can inspect every message in a session. It decides to which application server(s) the SIP message will be forwarded for the provision of services and it provides routing services. Most IMS networks will include multiple S-CSCFs to ensure availability of services to users and to distribute the signaling load. These S-CSCFs may be located over a wide geographical area.
According to current standards (see 3GPP TS 23.380) if a S-CSCF fails, the registration state of the failed S-CSCF can be restored at another S-CSCF so that operations can continue. However, when the user equipment (UE) that was allocated to the failed S-CSCF has been re-allocated to the new S-CSCF, this new S-CSCF may be located in a different region of the country than the UE. For example, the UE and the S-CSCF originally allocated to it may be in the West Coast region of the USA, whereas the new S-CSCF is in the East Coast region. It is clearly less efficient to direct signals over large distances, but for as long as the original S-CSCF is out of action, this may be acceptable. When the S-CSCF originally allocated to the user (which may be geographically close), it is preferable to switch the user back to this original S-CSCF.
Various proposals have been made for switching a user over to the “optimal” S-CSCF. One proposal is to use Administrative Deregistration procedures according to 3GPP TS 29.228. However, this will always terminate any existing sessions and dialogs that exist in the S-CSCF. This means that if the user is in a call, the call will be terminated.
Another proposal is to use re-selection procedures initiated by the I-CSCF. In this case, the I-CSCF first detects that the current S-CSCF is not optimal and needs to be re-selected, and secondly probes the current S-CSCF to check if there are active sessions in the current S-CSCF, and if not, selects a new, more optimal S-CSCF. (See 3GPP TR23.812 and until the latest version of this Technical report is available, see SA2 contribution S2-091406). One drawback with this proposal is that the re-allocation can only be done during a re-registration procedure. In addition, new functionality needs to be introduced both to detect that the S-CSCF needs to be changed and to re-select it. Furthermore, the proposed solution will introduce a new forking behavior in the I-CSCF (i.e., first try the current S-CSCF, and then try the new S-CSCF). This makes the I-CSCF stateful and changes the underlying principle of the I-CSCF functionality. These changes in the I-CSCF would also be quite expensive to implement. Finally, race conditions may arise if two UEs attempt to register at the same time.
In addition, neither of the proposed solutions described above take into account that even when a UE is not registered in IMS, a S-CSCF may still be allocated to a user for unregistered services.